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1. Introduction 

La sérialisatiorQ d'une valeur consiste à la représenter sous la forme d'une suite d'octets de 
sorte à pouvoir la sauvegarder dans un fichier pour relecture ultérieure ou la communiquer à 
d'autres programmes. Les langages de programmation statiquement typés cherchent à fournir, lors 
de la manipulation de ces valeurs dé-sérialisées, les mêmes garanties de siireté que pour les autres 
valeurs. C'est pourquoi on adjoint généralement aux valeurs sérialisées une information supplémentaire 
permettant d'attribuer un type correct à ces valeurs lors de leur dé-sérialisation (voir par exemple 

[m [ni m lin]). 

Le désavantage de l'adjonction de cette information de type est qu'elle peut rendre difficile la 
transmission de valeurs entre programmes écrits dans des langages différents, ou bien entre différentes 
versions d'un même programme. Le choix effectué par Objective Caml |16j de ne pas intégrer 
d'informations de type autres que celles nécessaires à la reconstruction de la valeur en mémoire dans 
les valeurs sérialisées est un facteur de simplicité, d'efficacité et de compacité. En conséquence, les 
fonctions de dé-sérialisation d'OCaml ne donnent lieu à aucune vérification, et la sécurité du typage 
repose sur la qualité des informations de type associées par le programmeur aux valeurs dé-sérialisées. 
Le programme utilisant ces fonctions de dé-sérialisation court donc le risque de rencontrer une erreur 
de type à l'exécution. 

Dans cet article, nous remédions à ce problème en proposant une façon de donner un type statique 
aux fonctions de dc-sérialisation en OCaml, d'utiliser ces types statiques pour effectuer des vérifications 
dynamiques lors de la dc-sérialisation et nous prouvons la sûreté de ces mécanismes. A l'évidence, 
lorsque les valeurs considérées sont ou bien des données atomiques ou alors des données structurées 
(non fonctionnelles) sans partage ni cycle, la vérification de l'appartenance d'une telle valeur à un 
type donné est très facile à mettre en œuvre : un simple parcours récursif est suffisant. Par contre, le 
problème devient plus complexe lorsqu'on est en présence de partage ou de cycles, sources potentielles 
de polymorphisme. 

Après une description des types que nous attribuons aux fonctions de dé-sérialisation à la section[31 
nous décrivons informellement l'ensemble du processus de vérification à la scction[31 La scction[3]décrit 

^En Anglais, on dit serialization ou marshalling, pour une mise en rang comme le ferait un officier {marshall ou 
maréchal), ou encore pickling, qui relève de la mise en conserve, comme en témoignent les pickles, petits cornichons 
conservés dans du vinaigre. Marshalling et marshall, s'écrivent indifféremment avec un ou deux £ |19) . 
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quels sont les programmes et les valeurs que nous eonsidcrons, ainsi que la traduction des programmes 
en valeurs. La section [5] décrit l'algorithme de vérification, et la section [6] en énonce les propriétés, 
et indique quelles sont les techniques utilisées pour les prouver. La section [7] décrit brièvement les 
implantations prototypes qui ont été réalisées, et les sections [8] et [9] mentionnent des travaux connexes 
et discutent quelques axes de travail futurs. 

2. Représentation dynamique des types statiques 

Vérifier dynamiquement le type d'une valeur dé-sérialisée impose d'avoir accès à une représentation 
de ce type au moment de la dé-sérialisation. Si c'était le cas, les fonctions de dé-sérialisation de valeurs 
depuis une chaîne de caractères ou un fichier pourraient avoir les typetH suivants : 

Marshal . f romString : Va.TRepr(a) String —>■ a 
Marshal . f romFile : Va.TRepr(a) — > Filenamie — > a 

011 TRepr est un type paramétré tel que la seule valeur du type TReprCr) est une description de la 
représentation des valeurs du type t. Pour r donné, nous noterons « r » cette valeur de type TReprCr) 
dans les exemples de programmes considérés dans la suite de cet article. Le programme suivant illustre 
l'usage d'une fonction de dé-sérialisation typée de cette façon : 

let xs = Marshal. f romFile « List(lnt) » "/tmp/f . dat" 
in List.foldLeft (+) xs 

Afin d'éviter toute interaction entre les variables de types pouvant apparaître dans « r » et dans le 
reste du programme, nous considérons qu'implicitement cette notation quantifie universellement les 
variables apparaissant dans r et représente ainsi un schéma de type clos. 

Cette possibilité de disposer des représentations de types à l'exécution sous forme de types 
singletons a été proposée par Crary, Weirich et Morrisett dans [5] et utilisée comme nous le faisons ici 
par Hicks, Weirich et Crary dans [T2]| . 

3. Présentation informelle 

Avant de procéder à la présentation détaillée des langages et systèmes de types nécessaires à 
la description de l'algorithme et à l'énoncé de ses propriétés, nous donnons dans cette section une 
description informelle du processus de vérification des valeurs dé-sérialisées. 

Parcourir type et valeur en parallèle Les fonctions de dé-sérialisation, munies d'une 
représentation de schéma de type, ont à vérifier que la représentation mémoire de la valeur v qui 
leur est présentée est compatible avec ce schéma de type. Cette vérification, qui utilise le type comme 
une contrainte que la valeur doit satisfaire, est réalisée par un parcours complet de la valeur avec, 
en parallèle, une expansion progressive du corps du schéma de type de sorte à exhiber le corps des 
définitions de constructeurs de type. Cette expansion permet, par exemple, de savoir que les seules 
valeurs possibles du type List(r) sont représentées ou bien par un entici|f| (pour le constructeur []) 
ou alors par un bloc marqué à 2 champs contenant respectivement des valeurs de types r et List(r). 
Notons que la représentation mémoire d'une valeur donnée peut être compatible avec plusieurs types 
non reliés : par exemple, l'entier peut être indifféremment vu comme booléen, entier, ou comme le 
premier constructeur constant d'un type arbitraire. 

^Nous suivons dans cet article la convention de notation préfixe des constructeurs de types où les noms de ces 
constructeurs commencent par une majuscule. Par exemple, le type OCaml int list est écrit ici List(Int). 
^Lc numéro d'ordre de constructeur constant dans la liste des constructeurs constants du type. 
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Isomorphismes de types et polymorphisme Si, durant ce parcours, nous sommes amenés 
à vérifier que la valeur est de type Va . (List (a) x List (a) ) et que la valeur courante est 
bien la représentation d'une paire (vi, «2), nous nous ramènerons à vérifier que vi et V2 sont 
toutes deux de type Va. List (a), c'est-à-dire List (Va. a). Intuitivement, une valeur de type 
Va. (List (a) xList (a) ) est nécessairement une paire de listes vides, et est donc aussi de type 
(List (Va . a) xList (Va . a) ) . Il s'agit là d'isomorphismes de types [6] qui nous indiquent que 
Va. (List (a) xList (a) ) est équivalent à Va/3. (List (a) xList (/3) ) , qui lui-même est équivalent 
à (List (Va . a) xList (V/3 . /3) ) . Le polymorphisme des valeurs de ce langage signifie une absence de 
composants (d'éléments, pour une liste, par exemple). Cette remarque permet donc de renommer les 
variables de type de sorte que chaque occurrence de variable soit distincte de toutes les autres, et invite 
à rapprocher chaque quantificateur de la variable qu'il quantifie. On transforme donc naturellement 
le type Vai,...,a„.r en T[(V/3./3)/ai]i=i..„. L'implication essentielle de cette remarque et de cette 
transformation sur l'algorithme de vérification est que si on est amené à vérifier qu'une (partie de) 
valeur est de type Va. a, alors l'algorithme termine en échecQ- 

Au lieu d'effectuer cette transformation, nous introduisons une nouvelle constante notée T, 
qui représentera Va. a, et on traduira le schéma Vai,...,a„.T en le type T[T/ai]i=i..„, obtenu en 
remplaçant toutes les variables de type apparaissant dans r par T. Nous noterons â les types obtenus 
de cette façon. L'algorithme travaillera donc avec un terme sans variables au lieu d'un schéma de type, 
et devra échouer lorsqu'il aura à vérifier que la valeur courante est du type T. L'équivalence entre ces 
deux notions de types sera formalisée par le théorème [TJ 

Partage Si la valeur à vérifier est un arbre (sans partage, donc), alors la vérification consiste en 
un simple parcours de la valeur en profondeur d'abord. Si, par contre, certains blocs sont partagés, 
il est tout-à-fait possible que l'un des pointeurs vers ce bloc contraigne ce dernier à être de type âi 
et qu'un autre pointeur lui impose d'être de type â2- Si âi et d-2 sont incompatibles, une façon pour 
ce bloc d'être à la fois de type âi et (T2 est d'être d'un type que nous noterons âi A â2 et qui est un 
anti- unificateur [2T1[T3] de âi et â2 ■ intuitivement, pour être à la fois de type âi et â2, la valeur ne 
doit pas avoir de composante qui soit particulière à un seul de âi ou â2- Notons ici qu'une fois cet 
anti-unificateur calculé, nous pouvons ne parcourir qu'une seule fois ce bloc partagé et les valeurs qui 
en sont issues. 

Cycles En présence d'un cycle, nous devons distinguer les pointeurs en provenance de r« intérieur 
du cycle », c'est-à-dire de la composante fortement connexe (CFC) à laquelle appartient ce cycle, des 
pointeurs en provenance de V« extérieur » de la CFC, c'est-à-dire du contexte de cette CFC. En effet, 
c'est le contexte qui fixera le type demandé à la CFC : les pointeurs en provenance du contexte sont 
porteurs de types qui sont anti-unifiés, comme précédemment. Une fois connues les contraintes de 
type imposées à chacun des nœuds racines de la CFC par son contexte, on parcourt récursivement 
cette CFC à partir d'une de ces racines, muni de la contrainte de type associée. Durant ce parcours, 
lorsqu'on rencontre des pointeurs vers les nœuds racines de la CFC, on vérifie que la contrainte associée 
à chacun de ces pointeurs est une instance de la contrainte émise par le contexte qui pèse sur ce nœud. 

Pour résumer cette présentation informelle de l'algorithme, le parcours de la valeur va être effectué 
en profondeur d'abord, retardant la vérification des nœuds partagés. Pour une valeur v dont le nœud 
racine est partagé n fois, une fois atteints les n pointeurs qui le désignent, on parcourt la valeur v 
récursivement. Si on a parcouru entièrement le contexte de v en ne rencontrant que m < n pointeurs 
vers V, alors le nœud racine de v fait partie d'un cycle : l'algorithme calcule alors ses CFC et les traite 
récursivement, l'un après l'autre, dans l'ordre topologique de dépendance. 

*La vacuité du type Wa.a est motivée par le fait que nous ne considérons que des données structurées complètement 
évaluées et non pas des calculs, comme on pourrait le faire dans un langage paresseux. 
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4. Programmes et valeurs 

Avant de décrire en détail la vérification des valeurs dé-sérialisées, fixons plus précisément les 
limites de cette étude : nous ne considérons dans cet article que les valeurs constituées de types de 
base et de types algébriques (enregistrements et unions discriminées). En particulier, on ne considérera 
pas ici les objets et valeurs fonctionnelles, les laissant comme axes de travail futur : ils posent en effet 
des problèmes a priori plus difficiles que les valeurs que nous étudions. Nous ne considérons pas non 
plus pour le moment les types de données mutables : nous y reviendrons à la fin de cet article. 

L'objectif principal est bien sûr de prouver que l'algorithme de vérification est correct (lemme 
m et théorème m, c'est-à-dire que si la vérification de v : â réussit, alors un programme e dont la 
sérialisation serait v possède effectivement tous les types représentés par â. Cela implique, par le 
théorème de correction du typage des programmes, que cette valeur v peut être utilisée dans un 
contexte d'exécution attendant une valeur de ce type. 

Un autre objectif est la complétude de l'algorithme (lemme [S] et théorème , c'est-à-dire que tout 
programme e de type r peut être sérialisé en une valeur v dont la vérification par l'algorithme réussira. 
Malheureusement, cette propriété n'est satisfaite que si la preuve de typage de e : r n'utilise pas la 
règle de typage polymorphe de la récursion [501 [T3]. Dans la pratique, l'effet de cette limitation restera 
probablement très marginal. 



4.1. Programmes 



Ce langage de valeurs correspond à un sous-ensemble des programmes source possibles. Puisque 
nous nous situons dans le cadre des langages à la ML, le langage source considéré, que nous appelons 
Val-ML, est donné par la grammaire suivante : 

entier 

variable indiquant un partage 
variable indiquant un cycle 



n 

P 
r 

(e, . . . , 
C. 

Fz(e) 
let {pi 
fix (ri 



e) 



,Pn) 

, r,,) : 



: e 
e 



in e 



n-uplet 

constructeur constant 
constructeur non constant 
partage 
cycle 



avec Pi S fv(e), Vi = l..n 
avec Ti G fv(e),Vi = l..n 

où fv(e) désigne l'ensemble des variables libres d'un programme e. 

Notons que l'on impose aux déclarations let et fix des programmes d'être utiles, c'est-à-dire de 
n'introduire que des noms de variables qui sont effectivement utilisés dans leur portée. La raison en 
est que ces programmes seront traduits en des valeurs qui doivent être des graphes connexes. Une 
déclaration de variable inutilisée contribuerait à produire un graphe non connexe. 

De plus, on prend soin de distinguer les pointeurs « internes » à une CFC notés r et introduits par 
la construction récursivc fix, des pointeurs « externes » symbolisant simplement le partage, notés p, 
et introduits par la construction let. 



Types des programmes Les expressions de type r sont formées à partir de types de base, de 
variables de types, et de types paramétrés. La notion de schéma de type (notés cr) est classique, ainsi 
que les définitions de type, notées S. 

T ::= a I Int I (r X . . . X t) | T{-t) 

a Va.T | t 

S ::= r(â^) = [Cil ... IC„IFi(t)I ... I Ffe(T) ] 
Les types de n-uplets sont notés comme des produits cartésiens d'arité variable. Pour simplifier 
la présentation, ces définitions de types sont considérées comme mutuellement récursives, et les 
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constructeurs de données qu'elles introduisent sont supposés distincts les uns des autres, afin qu'un 
constructeur de données identifie de façon non-ambiguë un constructeur de type. Ici, 'cî représente les 
paramètres formels du constructeur de types T, les Ci sont ses constructeurs constants et les Fi(_) ses 
constructeurs non constant^. 

Pour un programme donné, l'ensemble de ses définitions de types est noté A. En notant la 
substitution qui associe les aux 7?, on pose, pour T{li) défini dans A : 

A(r( r^)) = [ Cl I . . . I C„ I Fi(0(ri)) I ... I Ffc((?(rfe)) ] 

ce qui nous permet d'accéder directement à la définition instanciée de T. 

Environnement de typage Les environnements de typage sont notés F et définis par : 

F ::= I F©{p:cr} I F©{r :cr} 

On utilisera souvent F comme une fonction associant à un nom de pointeur q (où q est un pointeur 
p ou r) un schéma de type F(q). On notera dom(F) l'ensemble des variables q pour lesquels F(g) est 
défini et, F\{(7i, . . . , Çn} la restriction de F à dom{T)\{qi, . . . , Çn}. Enfin, on abrégera la généralisation 
d'un type r dans un environnement F en notant : 

gen(F,r) = VfV(7)\fV(fj ■ r 

Instanciation (polymorphe) On notera : 

- r < (T (r est une instance polymorphe de cr), si cr s'écrit VIÎ.t' et s'il existe une substitution 9 
telle que dom{d) = {~ct} et r = ^{t') ; 

- cr ^ ct' si toute instance polymorphe de a est aussi instance polymorphe de cr' (en d'autres 
termes, a' contient plus d'instances de type que cr). 

Etendant la relation d'instanciation polymorphe aux environnements de typage, on écrira F ^ F' si : 

- dom(F) = dom(F') ; 

- Vp G dom(F), T{p) ^ r'{p) ; 

- Vr G dom(F), F(r) F'(r). 

Remarquons que les pointeurs récursifs reçoivent un traitement spécifique : pour instancier un 
environnement, on ne peut instancier que les types associés à des pointeurs non récursifs (notés 
p). Les types associés à des pointeurs récursifs (notés r) doivent, quant à eux, rester inchangés à un 
renommage près, comme de coutume. Cette distinction est due au traitement différent reçu par les 
pointeurs de partage — pour lesquels des types distincts sont anti-unifiés — de celui reçu par les 
pointeurs récursifs, dont on vérifie simplement que le type est une instance du type du cycle dont ils 
sont racine. 



4.2. Valeurs 



Le langage des valeurs que nous considérons peut être représenté par la grammaire suivante. Les 
blocs représentent de la mémoire allouée et sont dotés d'une marque entière i, d'une taille n et de n 
valeurs contenues dans chacun des champs. Tous les pointeurs sont déclarés : ils indiquent la présence 
de partage ou de cycles effectifs. Aucun pointeur déclaré n'est superflu. La construction de ces valeurs 
à partir de leur représentation sérialisée est décrite à la section [T] 



n \ p \ r 
Block(i, «1, . . . , Vn) 
let {pi, . . . ,pn) = vmw 
fix (ri, . . . ,r„) = w 



entier, pointeurs et pointeurs récursifs 
bloc alloué de marque i > 1 et d 'arité n > 1 

partage 

cycles (composantes fortement connexes) 



^Nous ne considérons ici que les constructeurs de données constants ou unaires afin de simplifier la présentation. Les 
constructeurs n-aires induisent en effet des cas de preuve partiellement redondants avec le cas des n-uplets. 
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Types des valeurs Les types des valeurs sont construits comme les types des programmes où une 
constante notée T représentant le type vide, aura pris la place des variables de types. On les notera 
comme des termes de la grammaire suivante : 

â ::= T I Int I (cti X . . . X ct„) | r(CTi, . . . , ct„) 

On les définit formellement comme les représentants de classes d'équivalence de schémas de types clos. 
La relation d'équivalence est notée ~ et est définie par : 

Vai, . . . , a„.r V/3i, . . . , /3m. t' si et seulement si T^ijoix, ...,«„]= t'[7//3i, . . . ,/?„] 

où 7 est une variable « fraîche ». En d'autres termes, deux schémas sont équivalents s'ils ne diffèrent 
qu'aux occurrences de variables. Il est immédiat que cette relation est une relation d'équivalence. 

On se convainc aisément que chacune de ces classes d'équivalence contient des schémas de types 
qui sont isomorphes au sens que nous avons donné à la section[3l et le théorème [T] démontre que, pour 
une expression close e typable par un schéma de type clos cr, les différents membres de la classe de a 
sont aussi des types valides pour e. 

Le représentant de la classe d'un schéma a peut être calculé par la fonction univ ainsi définie : 



uriiv((ri x . . . x r„)) = (uriiv(ri) x . . . x unjV(T„)) 
umV(r(ri, . . . , r„)) = T(uiiiV(ri), . . . , unjV(Tn)) 
Inversement, on notera schema{â) le plus général des schémas de type de la classe représenté par â. 

On écrira ct ^ ct' si schema{â) ^ schema{â'). Et en notant F, F', les environnements de 
typage composés d'assertions de la forme g : ct, on étend cette relation d'instanciation polymorphe 
aux environnements de la même manière que pour les classes de types : en exigeant l'égalité sur les 
pointeurs récursifs. 

4.3. Traduction des programmes en valeurs 

Le passage d'un programme à une valeur est assuré par la fonction de traduction suivante : 



M = P 

M = r 

[(ei,...,e„)l = Block(0,|eiI,...,Ie„I) 

[Ql = i 

[F,(e)l = Block(ï,Iel) 

[let (pi, . . . ,p„) = e' in e] = let (pi, . . . ,p„) = |e'] in [ej 

|fix (ri,...,r„) = e] = fix (ri,...,r„) = |e] 



Cette traduction identifie les entiers et les constructeurs constants de même rang, ainsi que les 
constructeurs fonctionnels de même rang et de même arité. La vérification de types à laquelle on 
procède ici a pour but de lever les ambiguïtés introduites par cette traduction. 

4.4. Anti-unification sans mémoire 

L'anti-unification classique de deux termes du premier ordre produit un troisième terme, appelé 
anti-unificateur, dont les deux premiers sont des instances. Parmi les anti-unificateurs de deux termes 
donnés, le meilleur est celui qui est le moins général, instance de tous les autres. Classiquement, l'anti- 
unification produit donc des termes avec variables. Nous en donnons ici une définition légèrement 
différente, que nous appelons unification sans mémoire et qui n'utilise pas de variables mais la 
constante T, produite lorsque deux termes à anti-unifier entrent en conflit. Là où l'anti-unification 



univ{\/a.a) 
univ{a) 
umV(lnt) 



univ{a) 

T 

Int 
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classique produirait plusieurs fois la même variable, mémorisant ainsi plusieurs oceurrenees d'un 
même conflit, nous produisons plusieurs occurrences du terme T qui pourront être instanciées 
indépendamment les unes des autres, conformément à l'intuition que nous procure les isomorphismes 
de types mentionnés à la section |3l L'anti-unification sans mémoire de âi et â2 est notée âi A (72, et 
est définie par : 

Int A Int = Int 

(cti X . . . X CT„) A{â[x ... X â'J = (cti A ct'i X . . . X ct„ A â'J 

T(âi,...,â„) Ar(âi,...,â;) = r(âi A(7i,...,â„ Aâ^) siT^r 

âi A â2 = T dans tous les autres cas 

Dans la suite, ne faisant plus référence à l'anti-unification classique, nous écrirons simplement anti- 
unification pour dénoter l'anti-unification sans mémoire. 

On ajoute à notre algèbre de types un élément noté ±, neutre pour l'anti-unification. Cet élément 
sera utilisé comme hypothèse de type initiale pour les pointeurs lorsque l'algorithme entre dans leur 
portée, et sera nécessairement anti-unifié avec le type d'au moins une occurrence de ce pointeur : en 
effet, les contraintes de formation des programmes, qui imposent aux variables liées d'apparaître libres 
au noins une fois dans leur portée (aucune déclaration n'est inutile) sont, par traduction, transférées 
aux valeurs. Il en résulte que _L ne sera jamais utilisé comme argument de la fonction de vérification. 

5. Check, algorithme de vérification de types 

La vérification est représentée par le calcul de Chcck{T,â,v) où T est un environnement, et â 
et V sont respectivement le type et la valeur à vérifier. Un appel Check{T', tr, v) produira un couple 
(e,f') ou bien échouera. En cas de succès, f' est une généralisation de f (ce que montrera le lemme 
|3]), et e est un programme dont la représentation est la valeur v. Un appel initial à Check est de la 
forme Check(^,â,v) et produira une paire (e,0) en cas de succès. Un invariant de cette fonction est 
que fv{v) Ç dom(r) : en d'autres termes tous les pointeurs libres de v se voient attribuer un type 
(éventuellement _L) dans F. Il va de soi que dans une implémentation effective, cet algorithme se 
bornera à parcourir la valeur examinée et la rendre en résultat si la vérification réussit. 

On notera T ® {p : â}, l'environnement f" tel que T'{p) — r(p) A â et T'(j>') = r(p') pour p' ^ p. 

Ciieci(f,lnt,i) = (i,f) 

Checi(f,T(âi,...,â„0,i) = 
let [ Cl I . . . I C„ I Fi(âi) I ... I Ffc(â^) ] = A(T(âi, . . . ,â„0) in 
if < î < n then (Ci, F) else Failure 

Chccki^, T{âi, â,n), Block(i, v')) = 
let [Cl I ... I C„ I Fi(â'i) I ... I fkK)] = A(T(âi,...,â„)) in 
if < î < fc then 

let(e',r') = Check{t,âl,v') in 

(Fi(e'),f') 
else 

Failure 

Check{T, (cti X . . . X ct„), Block(0, vi, . . . , «„)) = 
let (ei,fi) = Check{T, âi,vi) in 

let (e„,f„) =_Check{rn-i,ân,Vn) in 
((ei, . . . ,e„),r„) 

Chcck{r,_â,p) 

{p, (f ® {p : â})) 
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CJiecJi:(r, â,r) = 

if (T ^ r(7') then (r, F) else Failure 

Chcck{T, tr, (let (pi, . . . ,_Pn) = u in w)) = 

let (e,f_') = Check{f® {pi : _L}i=i „,ct, w) in 

let (e',f") = CiecJc(f'\{pi, . . . ,p„}, (f'(pi), . . . , f '(p„)), z;) in 

((let (pi,...,p„) =e' in e),f") 

Check{V, (ôi, . . . , â-„)i (fix (ri, . . . , r„) = u)) = 
let r = r© {ri : âi}_i=i..„ in 
let (e, r") = C73ec]f(f ',_(5-i, . . . , ct„), w) in 
((fix (ri,...,r„) = e),f"\{ra,=i..„) 

Dans tous les autres cas : 

ChockiV, (T, v) — Failure 



6. Propriétés de l'algorithme 

Nous énonçons dans cette section les propriétés que satisfait l'algorithme de vérification. Nous en 
donnons aussi les schémas de preuves, mais invitons le lecteur à se reporter à |10| . où il pourra trouver 
les preuves complètes. 



6.1. Typage des programmes 

La discipline de typage à laquelle sont soumis les programmes est la discipline habituelle de typage 
de ML avec récursion polymorphe |20| . Puisque nous ne considérons pas les valeurs mutables, la 
généralisation n'est pas soumise à restriction. 

6.1.1. '^'^ , typage classique des programmes, avec récursion polymorphe 



, r < r(p) T < r(r) Vi = T : 

FF n : Int 



V\^'" p-.T Vf^'r-.T F \^'" (ei, . . . , e„) : (n x . . . x t„) 

QeA(T(r)) F,(t') e A(T(r)) F r e : r' 



F F C, : r(r') F F F,(e) : T( r') 

F 1^""'"° e' : (ti X . . . X t„) F @ fa : gen(F, Ti)}i^i..„ e : r 
F [^^^ let (pi, . . . = e' in e : T 

F ® {r, : gen(F, t;)}.=i..„ ^'^"^ e : (r{ x . . . x 

, ^ } — = L.n, T, < gen(F,Tj) 

F h fix (n, . . . , r„) = e : (n X . . . X T„) 

Rappelons [H] que si F' ^ F et F f^""''" e : r alors F' '^"'^^ e : t. 

6.1.2. \^ , un système de types alternatif 

Nous introduisons ici une manière de typer nos programmes modulo isomorphismes de types, 
associant à un programme e un type â, où les variables de types ont été remplacées par la constante 
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T. 

On définit le prédicat F F e : tr par le système de règles suivant : 

(T ^ f (p) tr ^ r(r) Vî = l..n, F \^ Ci : âi 

f[^n:lnt T p : â ff^riS f (ei, . . . , e„) : (âi x . . . x r„) f 1^ Q : r("CT ) 

f,{â') £ A(r(^)) r ^ e : r ^ (âi X . . . X g„) f ® {p^ : â^}^=i..n ^ e : â 

f^F,(e):T(^) f ^ let (pi, 

f © {r, : CT^},=i..„ e : (â; X . . . X ct;J 

1 1 — 

r h fix (ri, . . . ,r„) = e : ((Ti X . . . X cr„) 

Lemme 1 5i! f ' ^ f f e : ct, alors f ' e : ct. 

Schéma de preuve Par induction sur l'arbre de typage de f e : â. 

6.2. Équivalence entre H^'^"" et F 

Lemme 2 Soient un programme e, un type Te et un environnement T . Si T \^"" e : alors pour 
r = uniV(r) et CTe = uiuV(Te) on a ; f e : âe- 

Schéma de preuve Par réécriture systématique de l'arbre de typage de r e : Tg. 

Théorème 1 (Équivalence) Soient un programme e, un type â et un environnement T . Si T 'r e : â 
alors pour F ~ schemaiT) et pour tout r < schema{â) on a : T \^"" e : r. 

Schéma de preuve Par induction sur la dérivation du jugement f e : â et par cas selon la dernière 
règle utilisée. 

6.3. Correction 

Lemme 3 Soient une valeur v, un type â, et un environnement de type T tels que {v{v) Ç dom(r). 
Si Check{f,â,v) = (e,f') alors : 

1. dom(f') = dom(f ), 

2. f ' ^ f , 

3. M=v. 

Schéma de preuve Par induction sur les appels récursifs de Chcck{T , â , v) . 

Lemme 4 Soient une valeur v, un type â, et un environnement de type F tels que {v{v) Ç dom(F). 
Si Chcck{f,â,v) = (e,f') alors f ' e : â. 

Schéma de preuve Par induction sur les appels récursifs de Check{T , â , v) . 

Théorème 2 (Correction) Soient une valeur v, et un type â. Si Check(jè^ â,v) réussit en calculant 
un programme e, alors ; f-^ e : tr. 
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Preuve Le lemme [3] nous indique Check[% , a , v) = (e, 0). C'est ensuite une application directe du 
lemme |4l 

Le théorènie[5]et le lemme S] nous indiquent que si la vérification de v réussit en ct, alors l'algorithme 
produit un programme e dont la valeur est v et qui est typable par â. Cela rend bien évidemment 
inutile la production de e dans une implémentation effective de l'algorithme, qui peut se borner à 
rendre v en résultat en cas de succès. 

6.4. Complétude 

Notre algorithme n'est pas complet dans le sens où toute expression admettant une dérivation 
de typage dans \r'^ ne sera pas forcément acceptée par notre algorithme. En effet, les définitions 
de types non réguliers fournissent des contre-exemples, puisque certaines définitions de structures de 
données récursives nécessitent un typage polymorphe de la récursion pour être acceptées en ML. Soit 
par exemple la définition de type : 

Nest(a) = [ . . . I B(Nest(a x a)) I . . . ] 

et considérons la valeur fix (r) = B(r). On montre aisément que cette valeur peut avoir le type 
Nest(lnt) : 

{r : Va.Nest(a)} 'r'^ r : Nest(Q; x a) 

{r:Va.Nest(a)}r'"B(r):NestM ^ ^ 
—^^ (Nest(lnt) < Va.Nest(a)) 

%f fix (r) = B(r) : Nest(lnt) 

Cependant, lorsqu'on demande à l'algorithme de vérifier cette même assertion, celui-ci va échouer en 
tentant de vérifier que Nest(lnt x Int) < Nest(lnt). 

Nous allons montrer par contre que notre algorithme est complet pour toute valeur typable sans 
avoir recours à la récursion polymorphe. Soit \^'^ le système obtenu de '^'^ en y remplaçant la règle 
de typage polymorphe de la récursion par la règle classique de typage (monomorphc) de la récursion : 

r ® {r^ : T,},^i..„ f'^ e : (ti X . . . X t„) 
r [^^^ fix (ri, . . . , r„) = e : (ti X . . . x r„) 



Lemme 5 Soient une expression e, un type r et un environnement T tels que fv(e) Ç dom(r). Soient 
une substitution 9 et un type â tels que dom{6) = îviT) U iV(r), et fv(img(6))^dom(6) . Posons 
â = univ{9(T)). 

Si r \^"' e : T alors pour tout V r< 0{r), on a Chcck{univ(r'),â, |e]) = (e,f") où f" = umV(r") 
avec F" ^ 0(T). 

Schéma de preuve Par induction sur la dérivation de typage r f^^^ e : t, et par cas selon la dernière 
règle utilisée. 

Théorème 3 (Complétude) Soient une expression close e et un type r. Si \^'^ e : t, alors 
Ciiecif(0, univ(T), |e]) réussit. 

Preuve C'est un cas particulier du lemme El 
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6.5. Complexité du parcours 

Pour une valeur sans cycle, l'algorithme de parcours est linéaire en la taille N du programme la 
représentant. En effet, le choix d'anti-unifier le type de toutes les références à un bloc partage avant 
de parcourir ce dernier permet de ne parcourir qu'une seule fois l'ensemble de la valeur. En présence 
de cycles il faut ajouter au coût de ce parcours celui de l'identification et du tri des CFC, qui est dans 
le pire des cas de l'ordre de x P oii P est la profondeur maximale d'imbrication de constructions 
flx. 

7. Implantation 

Une implantation prototype de cet algorithme de vérification a été réalisée, ainsi que de certains 
éléments nécessaires à son intégration en OCaml. Cette section décrit quelques-uns des points 
importants de cette mise en œuvre ; le lecteur intéressé pourra se référer à [lOj pour y trouver une 
description plus précise. 

Représentation des types Les types abstraits et la compilation séparée font que lorsqu'on 
compile une valeur « r », on ne dispose pas statiquement de toutes les informations nécessaires à 
la reconnaissance des valeurs de type r. On résoud ce problème en compilant chaque déclaration 
de type comme une fonction ayant autant de paramètres que le constructeur de types. Ainsi, 
dans une expression « r », une référence à un type abstrait sera compilée comme un appel à 
la fonction correspondante dont le code ne sera accessible que lors de l'exécution, puisque fourni 
par l'implémentation de l'interface exportant ce type. Cette solution présente l'avantage de laisser 
inchangées les signatures de modules et de ne modifier que les implémcntations. 

Détection du partage et tri topologique Nous utilisons pour la recherche des CFC et leurs 
tris topologiques l'algorithme proposé par Tarjan |23j . Les informations sur le partage peuvent être 
accessibles en temps constant en encapsulant chaque valeur partagée dans un bloc spécial lors de la 
reconstruction en mémoire de la valeur dé-sérialisée. Cette capsule permet d'accéder aux informations 
nécessaires à l'algorithme de recherche de CFC, ainsi qu'au résultat de l'anti-unification des contraintes 
de type déjà rencontrées pour le bloc encapsulé. Chaque référence sur cette capsule n'étant suivie 
qu'une seule fois, le graphe mémoire réel de la valeur peut être reconstitué incrémentalement en 
remplaçant systématiquement la référence sur la capsule par une référence sur le bloc encapsule lors 
du parcours de vérification. 

L'algorithme de parcours d'une valeur, présenté à la section[31 parcourt les blocs du graphe mémoire 
d'une valeur dans le même ordre que l'algorithme Check. Chaque bloc partagé introduit une nouvelle 
construction let (p) = e in e' où p est une variable fraîche, e' le contexte déjà exploré et e la valeur 
représentée par ce bloc. Chaque CFC est représentée par une construction fix introduisant une variable 
pour chacune de ses racines. Des constructions fix imbriquées représentent des CFC internes à une 
CFC. 

8. Travaux connexes 

Les solutions apportées jusqu'à maintenant à ce problème se résument à sérialiser non seulement 
une valeur, mais aussi son type sous une forme ou sous une autre. Au début des années 1980, Herlihy 
et Liskov ont proposé une méthode de transmission de valeurs s'appliquant aux types abstraits dans 
le langage CLU [18] : les valeurs sont sérialisées avec leur type et des fonctions d'encodage et de 
décodage spécifiques fournies par les types abstraits sont utilisées à la place des mécanismes généraux 
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de sérialisation. Leroy et Mauny [17j ont étudie l'introduction de valeurs à types dynamiques en ML, 
étendant ainsi une proposition initiale de Cardelli dans le langage Amber [3]. Les valeurs à types 
dynamiques (ou plus simplement dynamiques) sont des paires composées d'une valeur v et d'un type 
T telles que w : t. La création de dynamiques nécessite la collaboration du compilateur, qui inclut le 
type statique r de la valeur v afin de créer le dynamique (w,t). Pour passer du dynamique (u,r) à 
la valeur typée w : r (le « déconstruire »), il est nécessaire d'avoir recours à un mécanisme particulier 
de filtrage qui réalise des tests de type sur les dynamiques. Puisque les dynamiques ont tous le même 
type, ils sont à même d'être manipulés par des fonctions de lecture et d'écriture typées. Les fonctions 
de sérialisation et de dé-sérialisation ont alors respectivement les types Dynamic — > Filename — v 
Unit et Filename — > Dynamic. On se retrouve alors dans une situation similaire au mécanisme de 
sérialisation actuellement implanté en Java. 

Les travaux de Dubois, Rouaix et Weis sur le polymorphisme générique [7] ont permis à Furuse 
et Weis de concevoir une forme de valeurs à types dynamiques, et de proposer des fonctions de 
lecture et d'écriture de valeurs avec leurs types. L'information de type qui est écrite est une empreinte 
cryptographique du type d'origine de la valeur, modulo renommage de labels et de constructeurs, 
fournissant ainsi une certaine souplesse grâce à la possibilité de renommage, et une efficacité des tests 
de type — nécessaires à la déconstruction des dynamiques — puisque seules des empreintes doivent 
être comparées. 

Leifer, Peskine, Sewell et Wansbrough [T5] s'intéressent quant à eux à la préservation de 
l'abstraction, renonçant donc à la souplesse mentionnée plus haut. Pour garantir la préservation de 
l'abstraction, ils associent aux valeurs l'empreinte cryptographique des définitions de leur type et de 
leur contexte (c'est-à-dire essentiellement le texte du module les contenant ainsi que les modules qui 
y sont importés). 

Du côté du monde objet à la Java, la dé-sérialisation d'un objet produit une instance du type 
Object. C'est ensuite le mécanisme de downcasting qui en assurera la spécialisation à la demande. 

L'approche que nous suivons se différencie clairement de ces travaux, en ce que, d'une part, nous 
considérons la dé-sérialisation de valeurs qui ne portent aucune information de type, et d'autre part, 
la vérification de typage que nous effectuons allie garantie et souplesse. 



Le problème de la reconstruction dynamique du type des valeurs dans les langages statiquement 
typés comme ML a surtout été étudié dans le cadre de l'interaction entre l'optimisation de la 
représentation des données et la gestion automatique de la mémoire (voir par exemple pi [51 [Tl [Ml H] ) . 
ainsi que dans le but de concevoir des outils de mise au point. La difficulté majeure à surmonter dans ce 
contexte est de retrouver les instances d'utilisation de valeurs polymorphes. En effet, un gestionnaire 
mémoire ou un debugger est amené à manipuler des valeurs résultant de calculs qui ont impliqué des 
utilisations d'instances particulières de valeurs polymorphes, et la reconstruction de ces instanciations 
est essentielle à l'obtention d'informations de types fiables sur la mémoire. Par exemple, une liste 
paramètre de la fonction List.length a pour type statique List (a) alors qu'un argument effectif 
de cette même fonction peut être de type List(Int) ou bien List (BoolxFloat) . Le problème de la 
reconstruction dynamique de types pour la gestion de la mémoire ou la conception d'outils de mise 
au point consiste donc à retrouver cette instance, en reconstituant l'histoire du calcul. 

En règle générale, cette reconstruction impose au programme de stocker suffisamment 
d'informations de type à l'exécution pour pouvoir reconstruire cet historique, pour garder trace des 
applications de fonctions polymorphes et prendre en compte les mutations et les levées d'exceptions. 
Par contre, ces travaux font l'hypothèse que cette information de type est correcte : on reconstruit 
donc le type d'un programme à un moment de son exécution mais on ne procède à aucune vérification. 

Le travail présenté ici ne nécessite pas de reconstruire ainsi le type d'un programme, mais vise au 
contraire à vérifier qu'une valeur appartient bien à un type. 
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9. Discussion et travaux futurs 

Un traitement correct des données mutables est indispensable avant d'envisager toute intégration 
dans un langage de programmation. Or, une utilisation naïve de cet algorithme de vérification sur des 
types de données mutables peut être source d'incohérences, lorsque le partage d'une valeur mutable 
lui impose d'avoir un type polymorphe, produit par anti-unification. Une solution évidente serait 
d'interdire de telles anti-unifications en faisant échouer la vérification lorsque celle-ci est amenée à 
anti-unifier deux termes partageant un même symbole de tête (constructeur d'un type mutable) dont 
les arguments ne sont pas identiques. Par exemple, si Ref est un type paramétré dont les valeurs sont 
des enregistrements avec un champ mutable, et que l'algorithme est amené à anti-unifier Ref(CTi) et 
Ref(â2), il échouera si âi et CT2 ne sont pas identiques. De tels cas d'échec peuvent être vus comme le 
refus du partage potentiel d'une occurrence mutable vue par le contexte comme porteuse de valeurs 
de types incompatibles : comme dans le cas non mutable, cela correspond à une absence de valeur au 
moment de la dé-sérialisation, mais le caractère mutable ne garantit pas la pérennité de cette absence. 

Nous n'avons pas abordé le problème des valeurs fonctionnelles dans cet article. OCaml permet 
leur sérialisation, sous la forme, essentiellement, de fermetures composées d'une adresse de code et 
d'un environnement. La de-sérialisation est capable de relocaliser de façon sûre l'adresse de code ; 
il reste donc, pour une dé-sérialisation sûre, à obtenir et vérifier le type de l'environnement. Or, ce 
dernier n'est généralement pas disponible : en effet le type d'une valeur fonctionnelle n'apporte en 
général pas d'information sur le type de son environnement. Nous envisageons dans un futur proche 
d'aborder ce problème. 

Le cas des valeurs de type TReprCr) mérite une attention particulière : en effet, elles peuvent 
elles aussi être sérialisées, et devront être dé-sérialisées de façon sûre. Par exemple, la sérialisation 
de la valeur ' 'Va-ListCa) ' ' doit pouvoir être relue comme étant de type TRepr (List (Int) ) ou 
Va .TRepr (List (a) ) , mais pas Va. TRepr (a). Il apparaît donc souhaitable d'autoriser la lecture de 
la représentation d'un type comme étant du type de la représentation d'une de ses instances. 

Le type TRepr étant prédéfini, il est aisé d'étendre l'algorithme Check par une analyse explicite des 
différents cas constituant le corps de sa définition, et faisant en sorte qu'il accepte la représentation 
de T comme étant du type de la représentation d'un type quelconque. 

10. Conclusion 

Nous avons présenté dans cet article une méthode originale de vérification de types de valeurs 
dé-sérialisées, et nous en avons prouvé la correction. Une implantation prototype en a démontré 
l'effectivité, et nous envisageons l'extension de la méthode aux données mutables et fonctionnelles. 
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